In many organizations, information used by an individual user is stored in multiple databases. There may be several reasons for this, but the use of many different computer tools very frequently leads to storage in different databases.
One context where this is particularly relevant is product or system development. Currently there are many different computerized system development tools; each specialized in specific development tasks or domains. Examples of such are Requirement Management/Engineering tools, System Architecture tools, Test Automation Tools, UML tools to mention a few.
In order to make development efficient, the information stored by the tools in different databases needs to be managed. Such management includes finding related information in different tools, traceability tasks, generating reports that gather information from different tools, accessing information in one tool from another, etc.
Historically, integration of development tools has been focused on either the format of information for transfer of information between the tools, or complete integration solutions for specific tools. This approach has been less than successful, mainly due to limitations and costs of the integration, and instead there has emerged standards for general exchange of information that go deeper into the interpretation and management of the information in the various tools. Examples of such standards include Requirements Interchange Format (RIF) (see e.g. http://en.wikipedia.org/wiki/Requirements Interchange Format) and XMI (see e.g. http://www.omg.org/spec/XMI/).
A limitation of these approaches is that they are limited to discrete ad hoc transfer of information from one tool to another. They do not provide a more systematic solution to the problem that information is stored in different databases.
Any database with identification of its data items can be integrated into another database by means of references to data items using the identification, thereby forming a “link”. FIG. 1 illustrates a link 5 from a primary item 1 in a first database 2 to a secondary item 3 in a second database 4. To make the link effective there must also be means of access to the secondary item 3 using the identification. Such simple linking, such as hyperlinks used in HTTP, supports access to data and possibly navigation or browsing in structures from one data element to another. However, with this approach it is not possible to trace a link backward, i.e. to detect within database 4 that there is actually a reference to the data item 3. As a consequence of this, data integrity cannot be maintained in one database; if item 3 is deleted, the link is “broken”. Further, it is not possible to perform set operations of data in multiple Data sources. Examples of such set operations are the “join”-operations available in SQL databases.
In order to overcome some of these limitations, data elements from one database can instead be replicated into another database. This is illustrated in FIG. 2. Here, a copy (replica) 6 of a secondary item is stored in the first database 2. This replica 6 can be accessed from the primary data item 1, and makes access to data quicker, as only one database is involved, and also enables set operations.
However, also this approach has other limitations. First of all, there is no systematic way to achieve the integration (replication), so it has to be performed from each database to another. Further, once the replication has been made, the first database, and its management system, cannot determine that the item is a replica, and even less where the original item is stored. In order to handle such problems, conventional databases employing integration by replication, require additional application software to keep track of which items are in fact replicas, and to handle the relationship between these replicas and the original items.
An example of a system for managing and updating data from different sources suffering from at least some of the above drawbacks is disclosed by WO2008151423.